1. Field of the Invention
The present invention relates to computer software, and deals more particularly with improved techniques for rendering content in a framework (such as a portal page provided by a portal system).
2. Description of the Related Art
The popularity of distributed computing networks and network computing has increased tremendously in recent years, due in large part to growing business and consumer use of the public Internet and the subset thereof known as the “World Wide Web” (or simply “Web”). Other types of distributed computing networks, such as corporate intranets and extranets, are also increasingly popular. As solutions providers focus on delivering improved Web-based computing, many of the solutions which are developed are adaptable to other distributed computing environments. Thus, references herein to the Internet and Web are for purposes of illustration and not of limitation.
The early Internet served primarily as a distributed file system in which users could request delivery of already-generated static documents. In recent years, the trend has been to add more and more dynamic and personalized aspects into the content that is served to requesters. One area where this trend is evident is in the increasing popularity of content frameworks such as those commonly referred to as “portals” (or, equivalently, portal systems or portal servers). A portal is a type of content framework that serves as a gateway, or focal point, for users to access an aggregation or collection of content from multiple sources. A portal provides its users with a Web page known as a “portal page”, often structured as a single overview-style page (which may provide links for the user to navigate to more detailed information). Alternatively, portal pages may be designed using a notebook paradigm whereby multiple pages are available to the user upon selecting a tab for that page. Some experts predict that portal pages will become the computing “desktop” view of the future.
Portal pages offer users Web pages that contain content from many different sources, and provide rich content to users in a compact form. Sources of portal page content include Internet sites, a company's intranet, news groups, applications, and other content management feeds. Many portals allow users to design a personalized version of the portal page, whereby the user can tailor the content, the layout, and/or the presentation attributes (such as color, font, etc.) of the page to his or her own preferences.
Portals are commonly designed using a component model that allows plugging components referred to as “portlets” (or, alternatively, components using a similar abstraction) into the portal infrastructure. Each portlet is responsible for obtaining a portion of the content that is to be rendered as part of the complete portal page for the user. The end result of the portal's content aggregation process is a Web page whose content is well suited for the needs of the portal user. FIG. 1 provides an example of a portal page 100 which includes three portlets 110, 120, 130. Portlet 110 in this example displays news headlines. Portlet 120 shows a stock ticker for the user's favorite stocks, and portlet 130 displays the current weather and weather forecast for the user's selected city.
While portal pages, by their nature, are rich in content, they are not without their disadvantages. Obtaining the content for the rendering can be a time-consuming process. In order to create a page of aggregated content, the portal must execute each portlet, wait for it to obtain and tailor its content, and then splice this content together into a markup language document representing the portal page it intends to send (as a stream) to the requesting browser. As a result of this process, the portal page renderer of the portal is unable to send content to the browser until the content generated by each of the portlets has been obtained. Thus, if one portlet takes an unusually long amount of time to acquire its content (for example, due to Internet delays, a server being down, and so forth), the portal user experiences having to wait a long time to see any content at all from his or her portal page. The user may think the portal is broken, or may simply become frustrated with using the portal. Many portal sites command a great deal of advertising revenue, due to their popularity with large numbers of users. Enterprises providing portals must therefore strive to keep their users happy, including avoiding these types of delays.
One prior art approach to reducing the time a user waits for receiving a portal page is to spawn individual threads for each portlet. This introduces concurrency into the computing time on the portal, and helps to reduce latency to a certain extent. However, it is still the case that the portal page cannot be delivered to the browser for rendering to the user until all the portlets have acquired their content.